home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20000217-20000824 / 000012_news@columbia.edu _Thu Feb 17 23:10:05 2000.msg < prev    next >
Internet Message Format  |  2000-08-23  |  2KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id XAA27550
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 17 Feb 2000 23:10:05 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id XAA13260
  7.     for kermit.misc@watsun.cc.columbia.edu; Thu, 17 Feb 2000 23:09:05 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Subject: Re: TELNET error with K95 1.19
  11. Message-ID: <3ERmaxlQV+sL@cc.usu.edu>
  12. Date: 17 Feb 00 20:34:22 MDT
  13. Organization: Utah State University
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <88id1n$ae2$1@news.value.net>, Mark Sapiro <msapiro@value.net> writes:
  17. > Bob Rodriguez <robertr@netcom17.netcom.com> wrote:
  18. > :   The new TELNET terminal negotiation options in version 1.19
  19. > : seems to have introduced a problem when telneting to special ports
  20. > : that are not Unix logins. There's a MUD that I was able to get to ok with
  21. > : 1.17 as candum.acc.umu.se 2001, but now it times out with the following errors:
  22. > <snip>
  23. > The short answer here is don't use the TELNET command if the
  24. > port doesn't speak telnet; use SET HOST instead.
  25. > For more info, see the thread "Help with telnet in C-Kermit 7"
  26. > from about a week ago in this newsgroup (you can look it up
  27. > at www.deja.com if it's gone from your news server).
  28. > -- 
  29. > Mark Sapiro <msapiro@value.net>       The highway is for gamblers,
  30. > San Francisco Bay Area, California    better use your sense - B. Dylan
  31. --------
  32.     Yup, that's the short answer. There could have been another approach
  33. to the difficulty which is a client offers Telnet Options but does not halt
  34. waiting for responses. In principle, it says in bold quotes, Options can
  35. occur at any time in the session, though the principle collides with what
  36. to do about text exchanged in the meanwhile. Isn't that correct Jeff?
  37. If it were correct then a regular Telnet client could offer Options and
  38. still make progress on non-Telnet servers. I wish my UnixWare Telnet were
  39. that way, but it isn't. This boils down to chickens, eggs, and should we
  40. wait to check for traffic before crossing the road, or some such muddle.
  41.     Joe D.